Details

Description

FINDING — MEDIUM (HTTP/1.1 keep-alive connections with trailers)
HttpConnection._trailers Cross-Request Leakage (Never Reset Between Requests)

Location:
jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/internal/
HttpConnection.java:107, 1157-1161, 1170

Detail:
_trailers (line 107) is a connection-scoped HttpFields.Mutable field.
parsedTrailer() (line 1157) populates it when request N carries HTTP trailers.
messageComplete() (line 1170) checks "if (_trailers != null)" — evaluates true
from request N's data — and stamps it onto request N+1.

Grep confirms: ZERO occurrences of "_trailers = null" in entire HttpConnection.java.

Scenario:
Request N: POST /upload (trailers: X-Checksum: abc123)
Request N+1: GET /data (no trailers)
app: request.getTrailers() on N+1 → returns {X-Checksum: abc123} ← STALE

Application logic branching on getTrailers() != null produces incorrect behavior.
Not cross-connection (same keep-alive connection only).

More dangerous scenario: TOCTOU — trailer passes check, target swapped before use.

Workarounds

Do not rely on HTTP request trailers for security-sensitive logic, or disable persistent connections by closing the connection after each HTTP/1.1 request.

Severity

• CVSS Score: 6.9 / 10 (Medium)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

References

• https://github.com/jetty/jetty.project/security/advisories/GHSA-f4v5-65jj-pcr2
• https://nvd.nist.gov/vuln/detail/CVE-2026-10051
• https://github.com/jetty/jetty.project/pull/15162
• https://github.com/jetty/jetty.project/pull/15163
• https://github.com/jetty/jetty.project/commit/72206b3ea623cf7ed8729b47a83ee628ff10e8eb
• https://github.com/jetty/jetty.project/commit/dc27e8d3ab743fe27935ea2d8c41756eb6c5bae9
• https://github.com/jetty/jetty.project/releases/tag/jetty-12.0.36
• https://github.com/jetty/jetty.project/releases/tag/jetty-12.1.10
• https://gitlab.eclipse.org/security/cve-assignment/-/work_items/119
• https://github.com/advisories/GHSA-f4v5-65jj-pcr2

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Details

Summary

Jetty currently accepts HTTP/2 and HTTP/3 requests where the regular
Host header and the pseudo-header :authority
do not match. As a result, the same request can carry two different host identities
through Jetty:

• logic based on HttpURI / Request.getServerName(request) uses :authority
• logic based on raw request headers continues to use Host

This creates a host/authority confusion condition that can break
security assumptions in higher layers.

Jetty already performs an explicit authority/Host consistency check on
the HTTP/1.1 path, but equivalent validation is missing on the HTTP/2
and HTTP/3 paths.

Security Impact

This issue is not inherently remote code execution, but it can become
security-relevant in deployments that rely on the request host for
security-sensitive decisions, including:

• host-based access control
• virtual host isolation
• multi-tenant routing by hostname
• login/logout/callback URL construction
• reverse proxy and forwarded-header trust chains
• auditing, cache keys, and absolute URL generation

Potential consequences include:

• bypass of host-based ACLs
• virtual host or tenant isolation failures
• incorrect or attacker-influenced redirect/callback targets
• inconsistent proxy/downstream interpretation of the original target host
• misleading logs and audit records

Technical Root Cause

1. On the HTTP/2 and HTTP/3 metadata builder paths:

• :authority is parsed separately into authority/URI state
• Host is preserved as a normal request header
• the two values are not compared for consistency

2. On the HTTP/2 and HTTP/3 server entry paths:

• Jetty calls ComplianceUtils.verify(httpCompliance, requestMetaData, listener)
• this verification does not enforce MISMATCHED_AUTHORITY

3. On the HTTP/1.1 path:

• Jetty explicitly checks whether authority and Host match
• mismatches are rejected by default

Relevant Code Locations

HTTP/2 metadata builder:

• jetty-core/jetty-http2/jetty-http2-hpack/src/main/java/org/eclipse/jetty/http2/hpack/internal/MetaDataBuilder.java

HTTP/3 metadata builder:

• jetty-core/jetty-http3/jetty-http3-qpack/src/main/java/org/eclipse/jetty/http3/qpack/internal/metadata/MetaDataBuilder.java

HTTP/2 server entry:

• jetty-core/jetty-http2/jetty-http2-server/src/main/java/org/eclipse/jetty/http2/server/internal/HttpStreamOverHTTP2.java

HTTP/3 server entry:

• jetty-core/jetty-http3/jetty-http3-server/src/main/java/org/eclipse/jetty/http3/server/internal/HttpStreamOverHTTP3.java

Shared HTTP compliance verification:

• jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/ComplianceUtils.java

HTTP/1.1 authority/Host consistency check:

• jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/internal/HttpConnection.java

Defined but not enforced on H2/H3:

• jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/HttpCompliance.java
• violation: MISMATCHED_AUTHORITY

Reproduction

I reproduced this on local Jetty 12.1.9-SNAPSHOT source.

Minimal reproduction steps:

1. Start a Jetty HTTP/2 or HTTP/3 test server.
2. Send a request with:
   • :authority = localhost:
   • Host = evil.example:
3. In the request handler, inspect both:
   • Request.getServerName(request)
   • request.getHeaders().get(HttpHeader.HOST)
4. Observe whether Jetty rejects the request or allows both values to remain visible.
   Observed result:
   • HTTP/2: request is accepted and returns 200
   • HTTP/3: request is accepted and returns 200
   • the server can observe both:
     • serverName=localhost
     • hostHeader=evil.example:

This shows that a single attacker-controlled request can preserve two conflicting host interpretations inside Jetty.

Tests Used

HTTP/2 rejection test:

• org.eclipse.jetty.http2.tests.HTTP2Test#testRejectMismatchedHostHeaderAndAuthority

HTTP/2 exploitability test:

• org.eclipse.jetty.http2.tests.HTTP2Test#testMismatchedHostHeaderAndAuthoritySplitsAuthorityFromHostHeader

HTTP/3 rejection test:

• org.eclipse.jetty.http3.tests.HandlerClientServerTest#testRejectMismatchedHostHeaderAndAuthority

HTTP/3 exploitability test:

• org.eclipse.jetty.http3.tests.HandlerClientServerTest#testMismatchedHostHeaderAndAuthoritySplitsAuthorityFromHostHeader

Observed behavior:

• both rejection tests fail because Jetty returns 200 instead of 400
• both exploitability tests pass, confirming that Jetty exposes different host values to different layers

Project-Internal Evidence of Real Impact

Examples:

• jetty-openid uses Request.getServerName(request) to construct redirect URLs
• jetty-ee11-proxy uses the raw Host header when building Forwarded

This indicates that the issue is not merely theoretical: Jetty’s own
ecosystem already contains code paths where different host sources are
used for different purposes.

Affected Version

Confirmed affected version:

• 12.1.9-SNAPSHOT

Other versions may also be affected if they share the same HTTP/2 /
HTTP/3 request construction and compliance-validation logic. I have
not yet completed a historical version matrix and would recommend
confirming exact affected ranges from Jetty’s branch history.

Suggested Fix

Recommend adding HTTP/2 and HTTP/3 validation equivalent to the
existing HTTP/1.1 authority/Host consistency check:

• if both :authority and regular Host are present
  • normalize and compare them
  • if they do not match, reject the request with 400 Bad Request
  • route the failure through the existing MISMATCHED_AUTHORITY compliance mechanism

Also adding explicit HTTP/2 and HTTP/3 regression coverage for this case.

Disclosure Status

• not publicly disclosed
• no public issue filed
• shared only privately with the Jetty security contacts

Severity

• CVSS Score: 5.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

References

• https://github.com/jetty/jetty.project/security/advisories/GHSA-7p3p-8qv8-m2vh
• https://nvd.nist.gov/vuln/detail/CVE-2026-6790
• https://github.com/jetty/jetty.project/issues/14870
• https://github.com/jetty/jetty.project/pull/14871
• https://github.com/jetty/jetty.project/pull/14897
• https://github.com/jetty/jetty.project/pull/14970
• https://github.com/jetty/jetty.project/commit/3e5a4daec196859b8886b6f67b1157dab47cdb6f
• https://github.com/jetty/jetty.project/commit/67ba9e6b39661810123680d9c894e99a7940c73d
• https://github.com/jetty/jetty.project/commit/cbca3076f7c914a232e7a8b22fa95fbf7e67a6cc
• https://github.com/jetty/jetty.project/releases/tag/jetty-12.0.35
• https://github.com/jetty/jetty.project/releases/tag/jetty-12.1.9
• https://gitlab.eclipse.org/security/cve-assignment/-/work_items/99
• https://github.com/advisories/GHSA-7p3p-8qv8-m2vh

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

v6.1.0

Compare Source

v6.0.3

Compare Source

• Fix checkout init for SHA-256 repositories by @​yaananth in #​2439
• fix: expand merge commit SHA regex and add SHA-256 test cases by @​yaananth in #​2414

v6.5.0

Compare Source

v5.6.0

Compare Source

What's Changed

• Backport to v5: Add Maven compiler problem matcher for javac diagnostics by @​brunoborges in #​1087
• feat: expose cache-primary-key output (#​597) [v5 backport] by @​brunoborges in #​1089
• dist: Cover Tencent Kona JDK 25 (#​1108) [v5 backport] by @​brunoborges in #​1110
• Backport #​1111: Preserve Maven toolchains across repeated setup-java runs (#​1099) by @​brunoborges in #​1113
• Backport #​1097/#​1098 to v5: cache Maven and Gradle wrapper distributions separately by @​brunoborges in #​1122

Full Changelog: actions/setup-java@v5...v5.6.0

v5.5.0

Compare Source

v5.4.0

Compare Source

What's Changed

• Bump @​typescript-eslint/parser from 8.48.0 to 8.61.1 by @​dependabot[bot] in #​1021
• Fix codeql workflow permissions by @​jsoref in #​993
• fix CodeQL permissions by @​gdams in #​1025
• fix: reject non-semver candidate versions in isVersionSatisfies by @​sproctor in #​1009
• Bump @​actions/cache to 5.1.0, handle cache write denied by @​jasongin in #​1026
• Add Maven Wrapper cache feature by @​mahabaleshwars in #​1027
• Spelling by @​jsoref in #​713
• add link to advanced configuration for JetBrains by @​robstoll in #​850
• docs(action): fix missing required or default fields by @​kranthipoturaju in #​1007
• feat: add microsoft openjdk 17.0.18 by @​al-kau in #​1002
• Update README.md - use "alert syntax for Markdown" for notes by @​mhoffrog in #​924
• Bump undici from 6.24.1 to 6.27.0 by @​dependabot[bot] in #​1033
• Update contributor guide with emoji for clarity by @​brunoborges in #​1028
• add javac problem matcher by @​Trass3r in #​562
• Clarify README version syntax and migration guidance by @​brunoborges with @​Copilot in #​1038
• Update undici artifacts to 6.27.0 (license cache + dist) by @​brunoborges in #​1040
• docs: enhance custom jdk file installation by @​stephanabel in #​996
• Templates for new Java distributions by @​panticmilos in #​429
• Bump actions/checkout from 6 to 7 by @​dependabot[bot] in #​1032
• Bump @​types/node from 25.9.3 to 26.0.0 by @​dependabot[bot] in #​1031
• docs: replace non-existent HelloWorldApp references with java --version by @​brunoborges with @​Copilot in #​1043
• docs: add JavaFX Maven project configuration instructions by @​brunoborges with @​Copilot in #​1044
• docs: self-signed certificate / internal CA handling for GitHub Enterprise by @​brunoborges in #​1050
• docs: document importing an internal CA into the installed JDK (cacerts) by @​brunoborges in #​1051
• chore: Harden workflows: least-privilege permissions + zizmor integration by @​brunoborges in #​1039
• dist: Add GraalVM Community distribution support by @​brunoborges with @​Copilot in #​1042
• docs: note jdkfile approach for Early Access / unreleased JDK builds by @​brunoborges in #​1058
• dist: Apply Copilot review suggestions from PR #​1042 (GraalVM Community) by @​brunoborges in #​1059

New Contributors

• @​jsoref made their first contribution in #​993
• @​sproctor made their first contribution in #​1009
• @​jasongin made their first contribution in #​1026
• @​robstoll made their first contribution in #​850
• @​kranthipoturaju made their first contribution in #​1007
• @​al-kau made their first contribution in #​1002
• @​mhoffrog made their first contribution in #​924
• @​brunoborges made their first contribution in #​1028
• @​Trass3r made their first contribution in #​562
• @​stephanabel made their first contribution in #​996

Full Changelog: actions/setup-java@v5...v5.4.0

v5.3.0

Compare Source

What's Changed

• chore: update Java version to 25 in setup examples by @​alaahong in #​969
• Bump minimatch from 3.1.2 to 3.1.5 by @​dependabot[bot] in #​984
• Refactor error handling and improve test logging for installers by @​chiranjib-swain in #​989
• chore: upgrade dependencies (@​actions/core, cache, glob, http-client, tool-cache, xmlbuilder2) by @​Copilot in #​999
• Add Oracle JDK 17 licensing limitation note by @​mahabaleshwars in #​1001
• Update readme for ubuntu sudo java_home behavior by @​mahabaleshwars in #​1013
• temurin: add support for Alpine Linux by @​gdams in #​674
• fix: resolve npm audit vulnerabilities in fast-xml-builder and fast-xml-parser by @​gdams in #​1015
• Bump @​typescript-eslint/eslint-plugin from 8.35.1 to 8.48.0 by @​dependabot[bot] in #​952
• Bump eslint-config-prettier from 8.10.0 to 10.1.8 by @​dependabot[bot] in #​881
• Bump picomatch, @​types/jest, jest, jest-circus and ts-jest by @​dependabot[bot] in #​1016
• Bump @​types/node from 24.1.0 to 25.9.3 by @​dependabot[bot] in #​950
• Implement pagination with link headers for Adoptium based apis by @​johnoliver in #​1014
• Make the Adoptopenjdk package type look at the Temurin repo first for latest assets by @​johnoliver in #​522
• Bump @​vercel/ncc from 0.38.1 to 0.44.0 by @​dependabot[bot] in #​1018

New Contributors

• @​alaahong made their first contribution in #​969
• @​Copilot made their first contribution in #​999
• @​johnoliver made their first contribution in #​1014

Full Changelog: actions/setup-java@v5...v5.3.0

v4.37.3

Compare Source

No user facing changes.

v4.37.2

Compare Source

• The new address format for the config-file input that was introduced in CodeQL Action 4.37.0 is now enabled by default. In addition to the format described there, the remote= prefix can now be used to explicitly indicate that the input refers to a remote file. All previous input formats continue to be accepted as well. #​4023
• The CodeQL Action can now make use of configured private registries in Default Setup to retrieve CodeQL configuration files from remote repositories that require authentication. This will allow customers to store their CodeQL configuration in a single repository that can then be referenced by Default Setup workflows in other repositories. We expect to roll this and other, related changes out to everyone in July. #​4007

v4.37.1

Compare Source

• Upcoming breaking change: Add a deprecation warning for customers using CodeQL version 2.20.6 and earlier. These versions of CodeQL were discontinued on 1 July 2026 alongside GitHub Enterprise Server 3.16, and will be unsupported by the next minor release of the CodeQL Action. #​3956
• Update default CodeQL bundle version to 2.26.1. #​4019

v4.37.0

Compare Source

• Update default CodeQL bundle version to 2.26.0. #​3995
• In addition to the existing input format, the config-file input for the codeql-action/init step will soon support a new [owner/]repo[@​ref][:path] format. All components except the repository name are optional. If omitted, owner defaults to the same owner as the repository the analysis is running for, ref to main, and path to .github/codeql-action.yaml. Support for this format ships in this version of the CodeQL Action, but will only be enabled over the coming weeks. #​3973

v4.36.3

Compare Source

No user facing changes.

v4.36.2

Compare Source

• Cache CodeQL CLI version information across Actions steps. #​3943
• Reduce requests while waiting for analysis processing by using exponential backoff when polling SARIF processing status. #​3937
• Update default CodeQL bundle version to 2.25.6. #​3948

v4.36.1

Compare Source

No user facing changes.

v4.36.0

Compare Source

• Breaking change: Bump the minimum required CodeQL bundle version to 2.19.4. #​3894
• Add support for SHA-256 Git object IDs. #​3893
• Update default CodeQL bundle version to 2.25.5. #​3926

v4.35.5

Compare Source

• We have improved how the JavaScript bundles for the CodeQL Action are generated to avoid duplication across bundles and reduce the size of the repository by around 70%. This should have no effect on the runtime behaviour of the CodeQL Action. #​3899
• For performance and accuracy reasons, improved incremental analysis will now only be enabled on a pull request when diff-informed analysis is also enabled for that run. If diff-informed analysis is unavailable (for example, because the PR diff ranges could not be computed), the action will fall back to a full analysis. #​3791
• If multiple inputs are provided for the GitHub-internal analysis-kinds input, only code-scanning will be enabled. The analysis-kinds input is experimental, for GitHub-internal use only, and may change without notice at any time. #​3892
• Added an experimental change which, when running a Code Scanning analysis for a PR with improved incremental analysis enabled, prefers CodeQL CLI versions that have a cached overlay-base database for the configured languages. This speeds up analysis for a repository when there is not yet a cached overlay-base database for the latest CLI version. We expect to roll this change out to everyone in May. #​3880

[v4.35.4](

✂ Note

PR body was truncated to here.